1. Field of the Invention
This invention relates in general to a method for programming IBM mainframe computers and, more specifically, to an access method for shared dataspaces under the MVS/ESA operating system.
2. Description of Related Art
Under the MVS/ESA operating system provided by IBM for use on its large-scale commercial mainframe computers, an address space for an application is limited to a size of 2 gigabytes, due to the 31 bit effective length of an address field. This amount of address space, however, may too small to meet the needs of applications that must have rapid access to large amounts of data.
To overcome this limitation, the MVS/ESA operating system makes available a feature known as a "dataspace," which represents an advance in data-in-memory technology. Dataspaces extend the reach of applications by providing additional data-only address spaces. Unlike an address space, a dataspace contains only user data; it does not contain system control blocks, common areas, or program code. The size of a dataspace can range up to 2 gigabytes, according to the request made by the application, thereby providing an application with access to multiple 2-gigabyte storage areas, i.e., its own address space and one or more dataspaces.
The MVS/ESA operating system also provides a data-in-virtual (DIV) feature for loading data into dataspaces. If the data to be loaded into the dataspaces is from a Virtual Storage Access Method (VSAM) linear dataset, then the DIV feature can map the data and move it directly from direct storage access devices (DASD) into the dataspace. The DIV feature also can move the data from the dataspace back to DASD. Using the DIV feature, the application does not have to use its address space as an intermediate buffer area for transferring data between DASD and the dataspace.
Despite these features, the MVS/ESA operating system does not provide an easily usable interface to make dataspaces readily sharable among a plurality of applications. The token offering provided with MVS/ESA, known as Data Windowing Services, does not adequately exploit dataspaces, and presents a difficult, unfamiliar programming interface to the programmer. The potential advantages of dataspaces remain untapped because of these shortcomings.
For example, suppose several applications simultaneously update a rate table that resides on DASD. When an application updates the table, it locks the table, reads part of the table into a buffer area in its address space, updates the table, writes the changes back to DASD, and unlocks the table. This creates contention among the applications trying to access that table as well as consuming I/O resources in the computer.
There are few realistic solutions to lessen the contention and consumption of resources caused by such activities. For example, each application cannot load a separate copy of the table into a dataspace because updates would not be uniformly applied to the table. Using client-server structures or cross-memory techniques to direct all updates to a single application that processes the updates against the rate table in its dataspace merely transforms the problem from DASD I/O contention into application I/O and/or memory contention.
Thus, there is a need in the art for a method of sharing accesses to global dataspaces among several concurrently executing applications, which method can be invoked by the applications programmer through a familiar, easy to implement, interface.